HTTPS 的整體流程

在上一篇中，我們提到了 非對稱加密 的機制，能夠安全的來進行金鑰交換。不過，整體上 HTTPS 的進行流程，不只是這樣而已。

首先照慣例，附上一張圖。

整體上來說，HTTPS 的流程是：

1. Hello - 客戶端和伺服器官表示想要發起 HTTPS 連線，說明自己支持的 SSL/TLS 版本和加密算法。伺服器端會回應客戶端說可以使用哪一種組合。
2. 憑證交換 - 伺服器必須照明_自己是誰_。伺服器會拿出一張憑證，基本上這張憑證記載了伺服器的身份、位置（網址）、憑證的公鑰、有效日期和數位簽章。客戶端會確認是否要相信這張憑證，要麼這張憑證是被設定要信任，要麼這張憑證是由某個信任的機構 (CA) 簽署的。另外，這個機制其實可以雙向使用，伺服器端驗證客戶端的身份，不過這個機制很少用到。
3. 金鑰交換 - 上一篇提到的機制。通過 Hello 步驟中獲得的資訊，雙方開始進行金鑰交換。交換成功之後，就能夠以對稱加密的方式來做通訊。

憑證

憑證的信任機制

一般來說，憑證要被信任，要滿足以下兩種需求之一：

1. 這張憑證是由某一個你信任的組織 (CA, Certificate Authority, 憑證授權中心) 簽發的 (root certificate, 根憑證)
2. 憑證本身的 CA，又能夠證明是被 #1 裡面的 CA 信任的 (intermidiate certificate, 中介證書)

通常 #1 比較單純，各家瀏覽器都會內建一份清單，記載有什麼 CA 是可以被相信的。要進入這個名單的流程非常的嚴謹，而且，由於事關重大，若 CA 做了什麼不太好的事情，那很快就會從這個清單內驅逐出去。不過實務上，除了看瀏覽器裡面的清單以外，也會看作業系統內帶的清單。兩份清單都可以自己做增減。

名單的控管，可以參考一下 Mozilla CA Certificate Store，至於從名單內被驅逐出的範例，可以參考一下 WoSign 和 中國官方的CA, CNNIC。

至於 #2 的部分，會需要「數位簽章」的機制來做驗證。

數位簽章

一張憑證可以被另一個授權中心做簽章的動作。正常狀況下，簽章代表著授權中心已經確認過原憑證持有方是真的擁有這個位置（網址）。實務上，這個授權中心會拿自己的私鑰去幫這張憑證的內容做加密，然後把這個密文嵌在憑證當中，當作數位簽章。這個流程和前述非對稱加密的流程是相反的，在數位簽章的狀況下，任何人都能拿這家憑證中心的公鑰去解開這張憑證，來確認這簽章是正常的。

所以流程是這樣：

1. 你要進行 HTTPS 連線，雙方做 Hello
2. 伺服器丟一張憑證給你，憑證上面寫說他被某 CA 簽了
3. 你剛好有這家 CA 的公鑰，拿公鑰解他的憑證，看是不是解的出來，內容是否正常
4. 繼續下一步

另外，這個方式可以連結很多張憑證，不過憑證一多，就要多花一點時間去檢查（重複2和3）。

常見的狀況：自簽憑證

因為之前提過，任何人都能夠隨便生憑證，重點是「這張憑證是否被大家相信」。有時候，在開發流程中，你會需要用 HTTPS，但你生不出一張正常的憑證（例如你根本沒網域，或是沒錢買，或是來不及弄），所以你就必須要自己當自己的 CA，然後自己用那個 CA 私鑰去生一張憑證出來。因為你自己的 CA 通常不會在信任名單裡面，所以大家跟你連線的時候，都會出現警示。

這種狀況下，你還是正在使用 HTTPS，所以資料傳輸過程有加密。不過，除非你將這張憑證加入信任清單，不然你沒有辦法防止別人做「中間人攻擊（即假裝他是那台伺服器）」。

機制弱點

前述提到，曾經發生過授權中心被除名的狀況。因為這些授權中心是可以讓任何憑證在大家的裝置上變得可用，因此，他們需要以非常嚴謹的態度來對待每一個憑證申請。被除名的 CNNIC，是因為某一間公司用中介證書簽了幾個 Google 網域底下的證書給其他人，而這張中介證書的根憑證是來自 CNNIC 的。因此，CNNIC 沒有做好管控措施，且這家公司是把憑證拿來做「竄改連線」的用途，因此就被除名了。

HTTPS 或是任何一個系統，都不是完全安全的。他防止不了有 CA 違規的情形、也防止不了你在服務裡面寫 shit logic。但是它還是一個很有效的資料傳輸方式。